Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ajout du champ notification_email pour les usagers, modifiable uniquement via l'api #5003

Merged
merged 14 commits into from
Feb 19, 2025

Conversation

Holist
Copy link
Contributor

@Holist Holist commented Jan 22, 2025

Closes gip-inclusion/rdv-insertion#2065

Contexte

Nous avons besoin de pouvoir assigner à différents usagers le même email de notification lors de la création des comptes pour les invitations à prendre rdv dans rdv-insertion dans le cas d'un couple conjoint demandeur RSA ou dans le cas d'un déménagement (plusieurs comptes seront créés sur les différents territoires).

Un début d'implémentation avait été réalisé en septembre dernier ici et ici. Il n'a pas été poursuivi car cela avait des répercussions trop importantes, notamment le renommage du champ email en account_email.
Suite à cela une spec fonctionnelle et technique a été réalisée pour évaluer les options possibles.
Une discovery a été mené par @NesserineZarouri à ce sujet pour identifier les besoins coté RDVSP.
Il en est ressorti qu'il n'y a pas de besoin de cette fonctionnalité aujourd'hui coté RDVSP.
On a donc décidé de choisir l'implémentation minimale de la fonctionnalité tout en pouvant évoluer plus largement au besoin.

Solution

On ajoute le champ notification_email pour les usagers.
Ce champ est modifiable uniquement via l'api.
Dans le front on affiche l'email de notification dans la show de l'usager si celui ci existe pour que les agents rdvi connectés à rdvsp puissent avoir l'information. On affiche également un avertissement pour expliquer que le champ n'est pas modifiable et a été renseigné par un partenaire externe.

Dans l'edit du formulaire de l'usager on affiche le champ email sauf si notification_email existe.
La traduction i18n des différents champs email/notification_email et preferred_email (l'un ou l'autre) est la même pour ne pas perturber l'agent avec ces notions.
Si un email est renseigné celui ci prendra la valeur du champ email et un callback effacera le champ notification_email de l'usager, les 2 ne pouvant pas être rempli simultanément.
Les mailers sont modifiés pour utiliser email ou notification_email en fonction de celui qui est rempli.

Techniquement et prochaines étapes

Coté rdv-insertion pour des mises à jour d'usagers existants nous allons modifier notre code ici pour interroger le show de l'api de rdvsp (celui ci renverra les valeurs des champs email et notification_email). Une fois qu'on a l'information on appellera l'update avec email ou notification_email en fonction.
Les nouveaux usagers seront toujours créés avec le notification_email :

Loading
sequenceDiagram
    participant RDVI as RDV-Insertion
    participant RDVS as RDV-Solidarités API

    alt Existing User (rdv_solidarites_user_id present)
        RDVI->>+RDVS: GET /api/v1/users/{id}
        Note over RDVS: Check which email field<br/>is currently used
        RDVS-->>-RDVI: Returns user with email fields infos
        
        alt User uses notification_email
            RDVI->>RDVS: PATCH /api/v1/users/{id}<br/>with notification_email
        else User uses email
            RDVI->>RDVS: PATCH /api/v1/users/{id}<br/>with email
        end
    else New User
        RDVI->>+RDVS: POST /api/v1/users<br/>with notification_email
        Note over RDVS: New users always use<br/>notification_email field
        RDVS-->>-RDVI: Returns created user
    end

    Note over RDVI,RDVS: All new users are created with notification_email<br/>Existing users keep their current field (email or notification_email)

A la suite de cette PR, nous envisageons une migration (copie de email dans notification_email et mettre email à nil) pour les usagers rdv-insertion qui sont uniquement dans des organisations rdv-insertion et qui ne se sont jamais connectés à l'application. Cela permettra d'avoir un état des enregistrements usagers cohérent avec le nouveau mode de fonctionnement.

Quelques chiffres sur les usagers concernés :

5716 usagers sur des verticales rdv-insertion uniquement avec un compte devise rdvsp activé. (Pas de migration)
242 940 usagers sur des verticales rdv-insertion uniquement et qui n'ont pas activé leur compte (à migrer de email vers notification_email). Cela représente 1/4 de l'ensemble des usagers de rdvsp.

700 usagers rdv-insertion avec un compte rdvsp activé sur plusieurs verticales. (Pas de migration)
14 928 usagers rdv-insertion avec un compte rdvsp non activé sur d'autres verticales. (Pas de migration)

@Holist Holist self-assigned this Jan 22, 2025
Copy link
Contributor

@francois-ferrandis francois-ferrandis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

J'ai fait un premier tour, je suis trop sous l'eau cette semaine car on est en sous-effectif, je reste bien chaud pour discuter des points soulevés, on peut s'appeler demain ou vendredi !

@Holist Holist changed the title Ajout du champ notification_email pour les usagers, modifiable uniquement via l'api (par rdv-insertion) Ajout du champ notification_email pour les usagers, modifiable uniquement via l'api Feb 11, 2025
@Holist Holist marked this pull request as ready for review February 11, 2025 15:20
- if user.notification_email.present?
li= object_attribute_tag(user, :notification_email, clickable_user_notification_email(user))
.text-muted.mb-2
| Cette valeur n'est pas modifiable et a été renseignée par un partenaire tiers (ex : rdv-insertion...)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Je reviendrais plus tard pour mettre une explication plus détaillée, mais je pense qu'on peut se passer de cette info supplémentaire, et toujours afficher le preferred_email ligne 9.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suite à notre discussion de ce matin j'ai fait un commit qui permet de modifier dynamiquement le champ email ou notification_email de l'usager à l'edit. L'agent n'est ainsi pas perturbé, n'a pas connaissance de la distinction email (devise) et notification_email. On a plus besoin de cette phrase.
4edfdb5

Copy link
Contributor

@francois-ferrandis francois-ferrandis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ça fait un peu peur mais c'est une bonne première étape avec la dé-corrélation des comptes et des profils ! 👌

Pour moi c'est OK de déployer ça. 🚀

A la suite de cette PR, nous envisageons une migration (copie de email dans notification_email et mettre email à nil) pour les usagers rdv-insertion qui sont uniquement dans des organisations rdv-insertion et qui ne se sont jamais connectés à l'application. Cela permettra d'avoir un état des enregistrements usagers cohérent avec le nouveau mode de fonctionnement.

Si j'ai bien compris, ça signifie que vos usagers ne pourront plus se créer un compte pour accéder à leur RDVs, c'est ça ?

Copy link
Contributor

@victormours victormours left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 Trop bien ! Merci pour le travail fait sur ce sujet, ça va être très utile pour la création d'usager dans le cadre des intégrations.
Comme on en a discuté, on peut merger ça, mais il faut réparer la recherche avant de s'en servir (en faisant attention à migrer les indexes de recherche de manière safe pour éviter de se retrouver dans un état où on n'a pas d'index et on casse l'application).
Ensuite il faudra assez vite permettre l'invitation d'un usager qui a juste un notification_email (probablement un ajustement à faire dans un controller devise, avec peut-être la possibilité de choisir une adresse mail différente de celle des notifications).
On pourra ensuite faire une migration de l'ensemble de la base.

Après ça, à plus long terme on pourra même imaginer du dédoublonnage de compte usager dans l'interface pour les usagers

@Holist Holist force-pushed the add_notification_email_field_on_user branch from 7310da9 to 1021793 Compare February 13, 2025 10:39
Copy link
Collaborator

@aminedhobb aminedhobb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀 🙌 💯 !

@Holist Holist merged commit 0f91609 into production Feb 19, 2025
15 checks passed
@Holist Holist deleted the add_notification_email_field_on_user branch February 19, 2025 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

[Bug] Un conjoint et un demandeur ne peuvent pas utiliser les mêmes emails de contact
4 participants